Boundary representation per feature methods and systems

ABSTRACT

Computer implemented methods and systems for CAD data exchange, and in particular for creating boundary representations (“breps”) on a feature-by-feature basis are disclosed. According to an embodiment of the techniques described herein, a parameterized feature from a parametric based design system is exported from a source CAD system ( 404 ). Iterative steps and complimentary extraction techniques are employed by one or more processors ( 452, 456 ) to create an importable design model of the parameterized feature ( 433 ), which is imported into a target CAD system ( 408 ). While the techniques can include API ( 436 ), pattern matching ( 440 ), and user emulation ( 444 ) techniques, they include a brep per feature ( 450 ) technique. By exporting the brep on a per feature ( 453 ) basis from the source CAD system ( 404 ), the design intent of a CAD designer can be preserved on importation into the target CAD system ( 408 ). In particular, where a parametric representation ( 433 ) of the feature fails to import into the target system ( 408 ), an unparameterized representation ( 453 ) of the feature can be substituted.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to U.S. Provisional Application Ser. No.60/297,014, filed on 8 Jun. 2001 and having the same title. Priority isclaimed to the '014 application. This application is also related toU.S. patent application Ser. No. 09/655,540, filed on Sep. 6, 2000,entitled “DATA EXCHANGE BETWEEN COMPUTER AIDED DESIGN SYSTEMS,” also towhich priority is claimed, and published PCT International ApplicationNo. PCT/IS00/01357, both filed on Sep. 6, 2000, also entitled “DATAEXCHANGE BETWEEN COMPUTER AIDED DESIGN SYSTEMS,” to which priority isalso claimed. All three applications are incorporated herein byreference in their entirety.

BACKGROUND

1. Field of the Invention

This application concerns data exchange methodologies for computer aideddesign systems, and in particular boundary representation techniques.

2. Background Information

In an earlier filed patent application, we discussed some of thechallenges and drawbacks of computer aided design (CAD) technologyemployed by engineers, scientists, and mechanical designers. Inparticular, a significant technical problem for such people is notalways the design work they do, but rather the means by which theirdesign work is shared and exchanged with other engineers, scientists,designers, manufacturers, and customers. Simply put, the problem stemsfrom incompatible, or differently modeled CAD file systems.

To solve these challenges, software designers typically approach theproblem from one of two ends. For instance, the most common approach isto conform design behavior on the front end. That is, to force the inputto parametric feature based design systems (PFBD systems) to conform tostandard syntactical structures. This approach is described by J. H. Hanet al. in Modeler-Independence Feature Recognition in a DistributedEnvironment, Computer-Aided Design, G B, Elsevier Science, Ltd.Publishers, B V, Vol. 30, No. 6, pp. 453-463, published May 1, 1998.

Another common approach is to focus on output file types. This approachhas been employed in various forms for years by the various CAD systemsvendors. IGES and STEP are standard output file types. A specificimplementation using such an approach is disclosed in U.S. Pat. No.5,717,905, by Iwamoto et al. (concerning Bezier-curve data conversion).

Another approach is discussed, albeit briefly, in Y. C. Kao et al.,Development of a collaborative CAD/CAM system, Robotics andComputer-Integrated Manufacturing, Elsevier Science, Ltd. Publishers,Vol. 14, 1998, pp. 55-68. While focusing on isolation issues attendantto coediting or collaboration in CAD/CAM design, that is multi-locationreal-time design, Kao et al. suggest that there are two alternatives fordata exchange between different CAD/CAM systems: one is by direct database conversation and the other is through a neutral data file. Choosingthe former, Kao et al. assert that the latter, neutral data exchangeformats, do not support collaborative editing. Moreover, Kao et al.provide no details, beyond co-editing of a non-uniform rational B-spline(NURBS) of how such a system might operate in practice on aparameterized feature. Significantly, the data exchange process itselfis secondary to the Kao et al. contribution: they are concerned withconnectivity and isolation.

SUMMARY OF THE INVENTION

Computer implemented methods and systems for CAD data exchange, and inparticular for creating boundary representations on a feature-by-featurebasis are disclosed. According to an embodiment of the techniquesdescribed herein, a parameterized feature from a parametric based designsystem is exported from a source CAD system. Iterative steps andcomplimentary extraction techniques are employed to create a substitutedesign model of the parameterized feature, which can be imported into atarget CAD system.

While the techniques can include API, pattern matching, and useremulation methodologies, they further include a brep per featuremethodology. Notably, the brep per feature and associated techniquesdescribed herein can be used to supplement the feature extraction andimportation techniques of earlier described systems, or they can be usedas a fallback mechanism when such earlier described techniques fail.

By exporting the brep on a per feature basis from the source CAD system,the design intent of a CAD designer can be preserved on importation intoa target CAD system. In particular, where a parametric representation ofthe feature fails to import into the target system, the brep of thefeature can be substituted and stitched to the solid the featuremodifies.

According to one embodiment, a computer implemented method for creatinga boundary representation on a per feature basis from a parameterizeddesign model comprises the steps of: extracting a parameterized firstfeature from a parametric based design model, the design model includinga plurality of features and corresponding to a source computer aideddesign system; creating a parameterized export version of the firstfeature; classifying the parameterized first feature with respect to atype of operation represented by the first feature; creating a boundaryrepresentation from the first feature, based on the step of classifying;and associating the boundary representation with the export version ofthe first feature for importation into a design model for a targetcomputer aided design system. In a similar manner, the boundaryrepresentation can be created completely independently of anyparameterized versions of the feature.

According to another embodiment, the method comprises: loading theparameterized design model from a source CAD system, the design modelincluding a plurality of features; classifying a first feature from theplurality of features with respect to a type of operation represented bythe feature; creating a brep from the first feature, based on the stepof classifying; and repeating the steps of comparing, classifying, andcreating for additional features in the plurality of features.Additional steps can include creating a parameterized representation ofthe first feature; associating the paramaterized representation of thefirst feature with the brep of the first feature; and repeating thesteps of creating the paramaterized representation and exporting foradditional features from the plurality of features.

According to one embodiment, a universal product representation iscreated to assist with the export/import process. The universal productrepresentation can exist as a temporary computer data structure, or itmay exist as a persistent data structure, to be used in subsequentoperations to export or import CAD data. The universal productrepresentation can include both a standard parametric based version ofeach feature, as well as an unparameterized (boundary representation)version of the same—or even multiple boundary representations of thefeature.

Additional steps, methods, techniques, and structures are disclosedherein for the CAD data exchange processes, including import and exportalgorithms, as well as techniques for determining the geometry of anobject before and after a feature is applied. For instance, facialdifference, solid difference, and boundary difference techniques are allset forth in the description below and in the accompanying figures andclaims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A-C graphically illustrate the orphan primitive. Morespecifically, FIGS. 1A and 1B depict paramaterized cylinders, while FIG.1C depicts an orphan of a cylinder.

FIGS. 2A-K illustrate a sewing primitive. More specifically, FIGS. 2A-Edepict a first feature applied to a solid, while FIGS. 2F-J depict asecond feature applied to the same object. FIG. 2K depicts a singlefeature both adding and subtracting from a solid.

FIGS. 3A-B illustrate additional aspects of a sewing primitive.

FIG. 4 depicts an overview of the data exchange process, which caninclude both export and import methodologies.

FIG. 5 is a flowchart depicting an export process.

FIGS. 6A-C are flowcharts depicting solid difference, facial difference,and boundary difference algorithms, respectively, which can be used inthe export process.

FIG. 7 is a flowchart depicting a brep per feature import process.

FIG. 8 is a flowchart detailing exemplary failure detection steps.

FIGS. 9A-C and 10A-D are diagrams corresponding to user emulation. Inparticular:

FIG. 9A generally shows a communication overview between exemplarysystem components; FIG. 9B is a screen shot detailing aspects ofselecting an object; FIG. 9C depicts monitoring display control data forchanges; FIG. 10A is a flowchart depicting the main steps for useremulation; FIG. 10B is a flowchart detailing exemplary set-upoperations; FIG. 10C is a flowchart detailing exemplary elementselection operations; and FIG. 10D is a flowchart detailing exemplaryverification operations.

FIGS. 11A-D and 12-17 depict edge selection techniques. In particular:FIG. 11A is a perspective view of a source object and an edge; FIG. 11Bis a perspective view of the source object with a feature applied to theedge; FIG. 11C is a perspective view of a target object and an edge;FIG. 11D is a perspective view of the target object with the featureapplied to the edge; and FIG. 12 is an operational overview of acomputer implemented edge selection process. FIG. 13 is a flowchartdepicting a method for detecting whether two edges overlap. FIG. 14 is adiagram of a source edge and a series of target edge candidates thatillustrates a technique for determining regions. FIG. 15 is a flowchartdepicting an edge containment algorithm. FIG. 16 is a flowchartdepicting a method for detecting an initial edge. FIG. 17 is a flowchartdepicting a chain extension algorithm.

FIGS. 18-20 are diagrams corresponding to feature pattern matching. Inparticular: FIG. 18 generally shows the data flow between exemplarysystem elements; FIG. 19 shows an exemplary data matrix; and FIG. 20 isa flowchart detailing exemplary feature pattern matching operations.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

When a geometric object is constructed in a CAD system, and moreparticularly a PFBD system, the solid is typically specified as asequence of operations, which are called features. Each of theseoperations creates new geometry or modifies an existing geometry. Theresult of the geometries, all of them together, is sometimes called aboundary representation, or “brep”. Hence, in ordinary usage, a brep isnot a feature, but the overall geometry of the object—the geometricpoint sets of the object which allow the object to be rendered in a CADsystem. Departing from common usage of the term, brep in this detaileddescription is inclusive of a brep of a feature.

In U.S. patent application Ser. No. 09/655,540 and published PCTInternational Application No. PCT/US00/01357, both filed Sep. 6, 2000,and entitled “DATA EXCHANGE BETWEEN COMPUTER AIDED DESIGN SYSTEMS”, bothof which are incorporated herein by reference in their entirety wherepermissible under applicable patent law, we disclosed methods andsystems for data exchange between CAD systems. More specifically, wedisclosed application programming interface, pattern matching, useremulation, and boundary representation techniques for exchanging designdata, including parametric based design data, between two differing CADsystems.

As a fallback to the first three approaches, exporting a boundaryrepresentation of the source design model into the target design modelwas employed. However, a drawback to this approach can be the loss ofdesign intent in the design model, which is embodied in the parametricsyntax.

This so-called “loss of design intent” can make features difficult toidentify; or, perhaps more aptly: the designer's intent more difficultto discern. When dealing with non-associative features, that is featuresthat are independent of other features, the loss of intent is notnecessarily a drawback, but when dealing with associative features, thatis features that are dependent upon other features, this loss can beproblematic.

For instance, for associative features such as a chamfer, the chamfer isapplied to an edge of a solid. (By associative, we mean that there issome sort of dependence in the operation that defines the feature onsome other feature—that is, the feature is associated with some part ofone or more other features.) If, for some reason, the edge in the solidcould not be identified, then the chamfer operation may be unable tooperate.

Our solution to this drawback is to export a boundary representation(brep) for each feature, rather than to export the brep for the entiresolid. In other words, we create an unparameterized representation of aparameterized feature. A primary advantage of this approach is thatfeatures for which parameterized representations can be created areallowed to persist, rather than being subsumed into a larger boundaryrepresentation. Consequently, less parametric information is lost in theCAD data exchange.

Another advantage is that a fallback mechanism can exist whenparameterized data exchange fails or simply does not exist. (We notethat the brep per feature approach can be performed on all of thefeatures, only user specified features, only features that otherwisefail parameterized import, or any combination of the above.)

The result is that more design intent can be preserved using our brepper feature (BPF) approach. The methods and systems associated with BPFare described in further detail below.

BREP PER FEATURE PRIMITIVES

Before beginning detailed discussion of the overall process, someinitial matters warrant discussion. The brep per feature approach weundertake currently has four primitives—that is, building blocks for theBPF mechanism. For the purpose of illustration, we will refer to theseprimitives as orphan, sew, Boolean operations, and hybrid features. Acommon characteristic of the primitives is that they are eachunparameterized.

Turning to FIGS. 1A-C, they graphically illustrate the rewrite processto an orphan primitive. The orphan primitive is used to createunparameterized solids or skins from a boundary representation, theorphan being a feature that holds the boundary representation.

In FIG. 1A a feature, here a cylinder 104, is shown. The parameters ofthe cylinder 104 include its radius 108 and height 112. In FIG. 1B, thecylinder 104 is re-written as an extrude operation performed on asection, here the section 116 is specified and a directional vector 120is a parameter.

In FIG. 1C the parameterized feature of FIGS. 1A or 1B is re-written asan unparameterized feature. Here, the unparameterized feature is anorphan 124. The orphan in this example comprises four vertices(128-140), five visible edges (144-160) connecting these vertices, andtwo visible faces (164 and 168) created between the connected sets ofedges and vertices—each is called out in the drawing. Not visible inFIG. 1C are two faces (opposite face 168 and another opposite face 164),and one edge (complimenting edge 152 and separating the two hidden facesopposite face 164 and face 168).

If a feature (for example: a cylinder, a box, a sphere, anextrude-create, a loft-create, a close, an offset operation, or anotheroperation) has a non-associative property, then the operation isclassified as a pure creating operation. Pure creating operations can bere-written using the orphan primitive as is depicted in FIGS. 1A-C.

The sewing primitive is best illustrated with reference to a roundfeature applied to a solid. For this we turn to FIGS. 2A-E. In FIG. 2A,a solid 204 is shown. In FIG. 2B, a round operation is performed on anedge 212 of the solid 204. (Note that the round operation is notcompleted as shown in FIG. 2B, but would be as shown in FIG. 2E.) Whenexporting the parameterized round feature from the source CAD system'sdesign model, it is possible that the round fails to import into atarget CAD system. In such a case, the sewing primitive is a goodfallback mechanism.

The sewing primitive takes two arguments as inputs: a skin and a solid.The skin is sewn to the boundary of the solid, the solid on the materialside of the skin is kept, and the solid on the non-material side of theskin is discarded. Preferably, two conditions are satisfied for thesewing operation. First, the edges of the skin on the boundary of theskin, i.e., the free edges, must lie on the faces of the solid. Second,the skin should partition the solid into regions that are on thematerial side of the skin and regions that are on the non-material sideof the skin.

Explained another way: create edges on the solid where the free edges ofthe skin exist. Next, with an imaginary pair of scissors, cut theboundary of the solid along the free edges of the skin. This willpartition the solid into disjoint skins. Next, discard the skins thatare not oriented properly with respect to the skin that we are sewing.Two skins can be said to be properly oriented if they can be stitchedtogether and have a consistent material side. Finally, stitch theremaining skins together with the given skin. Any of the figures can beused to illustrate this example, and in particular FIG. 2K. (Anotherexample of the conditions is presented below with reference to FIGS.3A-B.)

Returning to FIGS. 2B-E, in FIG. 2B the solid 204 is depicted togetherwith a skin 208, the skin 208 representative of a round operation.

Turning to FIG. 2C, note that the region 216 called out by the circlelies inside the material region of the solid 204. The first condition,described above, is not satisfied by the lower edge of the skin 208.

Referring to FIG. 2D, a minimum set of faces is selected that define theround. Here, the face representing the round 220 is selected, as is abordering face 224 on the solid 204. Note that two faces are selected inFIG. 2D, as either face alone would not satisfy the first condition.Also note that the face selections partition the solid into regions onthe material side and non-material side of the skin 228. After selectingthe faces, the skin 228 (which is the combination of the two selectfaces 220 and 224) is sewn to the material side of the solid 204 and theregion in the non-material side is disregarded. The result is shown inFIG. 2E as a solid 204′.

Turning next to the sequence of FIGS. 2F-J, they depict a roundoperation that is adding, as opposed to subtracting, from the solid (thesame solid depicted in FIG. 2A). As the process was already above withrespect to FIGS. 2A-E, it will not be labored again. Rather, particulardifferences are pointed out. Furthermore, as is depicted in FIG. 2K, asewing operation can both add and subtract material from the solid 204′″at the same time (added material 252, subtracted material 256).

FIG. 2F depicts a round applied between two faces of the solid 204, andmore particularly above the edge 236, which is substantially hidden. Theround is depicted as a skin 232. Turning to FIG. 2G, a portion of theregion beneath the face 232, but above the original solid 204, is calledout as region 240. An objective with a skin like skin 232 is to sew itto the solid 204.

FIGS. 2H-I illustrate the face selection process. FIG. 2H being a firstset of faces 244 effected by the feature, and FIG. 2I being all thefaces 248 effected by the feature. FIG. 2J depicts the final solid withthe skin stitched to it; it is called out as solid 204″.

It is noted here, with respect to FIGS. 2F-2J, and will be discussedbelow with reference to FIG. 6C, that a boundary differences algorithmcan also be used for calculating the resultant solid 204″. Notice inFIGS. 2F-G that a small portion of the horizontal face that connects toedge 236 is hidden. Together the face 232 and the vertically orientedpseudo-triangular face 234 represent the minimal skin, with respect tothe surface area, that can be used to reconstruct the round featureusing the sewing operation. This minimal skin is precisely the boundarydifference between the solid 204″ (after the round) and the solid 204(before the round). The brep of the boundary difference can be used toreconstruct the round feature using the sewing operation. Again, this isillustrated here because of its relationship to the sewing primitive andalso because it graphically illustrates the boundary differencestechnique discussed below.

Returning to the conditions that are preferably satisfied for selectingfaces of the skin, we turn to FIGS. 3A-B. Each figure depicts a solid304 with a round applied to an edge 308. A skin 312 on each solid,delineated by heavy lines, captures the round feature. Notice that eachskin 312 has two faces (316 and 320). While there are five faces (onenew face lying on the new surface created by the round and four facesthat were modified by the round—these faces adjacent to the new face)that completely define the round, two are sufficient.

To determine the faces, a naming system, for example the one describedbelow, can be employed. In one embodiment, the naming system returns thefaces that remained exactly the same after the operation (here, theoperation being a round). Thus, knowing all faces, the remaining facesare the faces that completely define the operation. This can be called a“strong naming” system. In another embodiment, a “weak naming” systemcan be employed, the weak naming system indicating the new face(s)created by the operation. Using a weak naming system will typicallyrequire selection of the adjacent faces as well. The faces ultimatelyused would be those faces meeting the criteria above. Note, however,that this is an optional step that optimizes the algorithm.

The first condition, on the free edges of the skin, is satisfied. Thefree edges of the skin lie on the faces of the solid 304. Note thateither face, alone, does not satisfy this condition. The secondcondition, that the skin partitions the solid into regions, is alsosatisfied: here, there is a material side and a non-material sidecreated by the skin. Note the faces removed by the skin, namely thosefaces incident to dashed line 324.

It is possible for multiple skins to be reflected in a feature. Intarget systems that do not support a multi-sewing operation, themultiple sewing operations are performed as a series of single-sewingoperations.

Another primitive is a Boolean operation. Boolean operations includeoperations between two solids, such as unite, subtract, and intersect.In addition to being operations between solids, the Boolean operationscan be between a solid and a skin. For instance, Boolean operation canbe used in replace of a sewing operation. Furthermore, if the above twoconditions referenced above with respect to the sewing primitive aresatisfied, then it is possible to re-write the sewing operation as twoBoolean operations: first the non-material side of the skin issubtracted from the solid, then the skin is united with the result.

A fourth primitive is the hybrid primitive. It is a combination of anyof the three primitives discussed above. For example, a hybrid primitivecan be an orphan-add or an orphan-sew combination.

Brep Per Feature

Now that the primitives are described, a functional description of CADdata exchange with BPF is presented. Turning to FIG. 4, it is aflowchart depicting a scenario under which the BPF methods and systemswould be employed. As was mentioned above, BPF is envisioned to beemployed as a complimentary algorithm for CAD exchange, and inparticular where the data exchange is between computer aided designsystems that have otherwise incompatible file structures. While thedescription and the accompanying figures are described with this legacyin mind, it is appreciated that the forgoing techniques can be employedin other environments and independent of a failure of another CAD dataexchange technique.

According to one embodiment, the primary components of the data exchangesystem are a source CAD data model 404, a target CAD data model 408, andone or more processors (e.g. processors 452 and 456), and computersoftware product (configured to implement the functionality and/or stepsdescribed below). An export process 412 operates, by way of computersoftware product executed on processor 452, on the source CAD data model404 to extract the features from the model 404. In a complimentaryfashion, an import process 416 operates through processor 456 on theexported data model 451 (also called a universal product representationor “UPR”) from the export process 412 to input the UPR 451 in arepresentative fashion into the target CAD data model 408. It is notedthat the UPR 451 from the export process 412, and the input to theimport process 416 can be transitive in nature or persistent.

The export process 412 is depicted as a series of functional blocks.Each bock can comprise sequences of computer program code that isdivisible from the other blocks. Block 420 is the scene object builder,which calls one or more object builders 424. The object builders 424construct the elements of the data model from a feature tree. For eachelement identified from the scene object builder 420, a decision tree428 is used to locate the appropriate object builder 424 to call. Theobject builders 424 perform iterative export methodologies 432 in anattempt to create the element.

According to one embodiment, the export methodologies include anapplication programming interface mode 436, where an API in the sourceCAD system is used to create the element, a pattern matching mode 440,where recognized operations form the source CAD data model 404 aremapped to corresponding operations in another data model or intermediatemodel. The export methodologies can further include a user emulationmode 444, where user emulation techniques are used to emulate theactions of an actual CAD user in a creation, selection, or exportprocess, as well as examining data sent to a display, and usingpull-down menus generated for the display, and a boundary representationmode 448. The boundary representation mode 448 further includes aboundary representation on a feature-by-feature basis (BPF module 450).

Each export methodology compliments the others. For instance, in usingthe API, user emulation may be necessary. Furthermore, we can export aBPF even if the API, pattern matching, user emulation, or anycombination of the above are successful in creating a parameterizedrepresentation. Likewise we can, instead or further, export an entirebrep.

The data result of the export process 412 is a computer readable datastructure UPR 451, which comprises a standard parametric representation433 of a feature (for example a parametric representation of the featurein a non-native format), and an unparameterized representation 453 ofthe feature (for example a brep). According to one embodiment, multiplebreps for a single feature are included in the UPR 451, each beingcreated by a unique algorithm.

Before moving on, it is noted that the UPR 451 can include a pluralityof features, each feature having a parameterized representations 433 andan unparameterized representations 453. Corresponding (or “matching”)representations 433 and 453 can be logically or physically associated(or “attached”) to each other. For instance, a data dictionary in theUPR, or corresponding thereto, can make the appropriate associationsand, for example, specify the mode or operation(s) by which therepresentations were created. Alternatively, the UPR components can byphysically arranged so that their relationship is implicit or called outby some other identifying data.

Once the source CAD data model 404 is exported, the import process 416takes over. Here again, the blocks can be represented physically asmultiple blocks of computer program code, which are executed by aprocessor, such as processor 456. The processor 456 is typicallyassociated with the target CAD system.

Continuing with the data flow through the system, the UPR 451 from theexport process 412 is processed by the import software 416, whichoperates one or more processors as follows: Each of the features fromthe export 412 is looped over in some order. This order can be userspecified, data structure specified (for instance from the data model inthe source CAD system), CAD system specific, or specified by anothermeans. For each feature, an import action module 460 is called. Theimport action module 460 comprises import actions 468, which areprocedures that import particular features (the subject feature) intothe particular target system 408.

If an import action 468 does not exist or fails to execute successfully,then a simplifier module 462 is invoked. The simplifier module 462 callsa rewrite function 464. The rewrite function 464 rewrites the feature asa different feature or a set of features. After the rewrite function 464is completed, then the import action module 460 again attempts an importaction 468. (It is noted that the simplifier modules are described ingreater detail below with reference to FIG. 7.)

If the rewrite function 464 and second import action 468 are notsuccessful, then the simplifier 462 rewrites the feature to an orphanfeature. If the orphan feature has a brep (BPF), then the simplifier 462succeeds, otherwise it fails. (It is noted that for simplicity, only tworewrite 464 and import 468 actions are described. In fact, severaliterations of the two can be attempted before the orphan feature iscreated.)

For instance, if a brep for a feature is a single skin, then thesimplifier 462 can re-write the feature as an orphan-sew operation. Onthe other hand, if the brep for a feature comprises multiple skins, thenthe simplifier 462 can re-write the feature as a series of orphan-sewoperations (a “multi-sew” operation). Further still, if the brep is asingle solid, then hybrid re-writes can be implemented by thesimplifier, such as an orphan-create, add, cut or intersect.

Export Algorithms

FIG. 5 is a flowchart depicting a BPF export algorithm according to anembodiment. In step 504, the source CAD data model is loaded into memoryassociated with the processor that performs the export process. In step508, features from the loaded data model are interrogated against aknowledge base so that they can be classified. The classification stepsare further shown in FIG. 5 as decision boxes 520 and 536.

In box 520, a decision is made as to whether the feature is a creatingoperation. A general characteristic of a creating operation is that theoperation creates a standalone solid. For instance, creating operationsinclude solid primitives, such as block, cone, cylinder, and sphere.Creating operations can further include section-based primitives, suchas extrude, revolve and sweep.

While this classification technique is a rule of thumb, it is notnecessarily the end of the inquiry. For instance, our experiments havedetermined that in certain CAD systems, hybrid features, such asextrude-add, may or may not be classified as creating operations.

For instance, in a UniGraphics CAD system, the solid created by theextrude-add operation is no longer standalone. In such a case, certainknown hybrids and exceptions may be further tested, beyond the generalclassification, to determine whether they fall out of the creatingoperation classification.

A second test, depicted as box 524, is thus shown. The test isconfigured to determine whether the feature is the result of a hybridoperation. If the operation is a hybrid operation, then processingcontinues to step 540, which is described below. However, if theoperation is not a hybrid operation, then in step 528 a brep of theentire feature (BPF) is exported. From step 528 the process canterminate or move on to a next feature.

In box 536, a decision is made as to whether the feature results from alocally modifying operation. Modifying operations can result in featuresthat locally modify the brep topology, as is the case in the operationsround, chamfer, and draft. These operations create skins, which arecombined with the associated solid using the sewing primitive (describedabove).

According to an embodiment, a partial brep is exported that comprisesone or more skins, preferably using the facial differences technique,which is again described below with reference to FIG. 6B. In anotherembodiment a boundary differences technique can be employed, which isdescribed below with reference to FIG. 6C.

However, the feature may have resulted from a globally modifyingoperation. A general characteristic of a globally modifying operationthat it modifies an entire solid. An example of such an operation is theshell operation. If the operation is a globally modifying operation,then a partial brep can be exported using a solid differences technique(FIG. 6A).

However, in another embodiment, and in particular in some CAD systems,it can be easier to extract the skins for globally modifying operationsthan compute the solid that is defined by these features. Returning tothe solid difference technique, in the case of a regular shell operationperformed on a block, the solid difference is the cavity created by theshell. That is, we process the modifying operation (here, “unary”operation can be more apt) by exporting a brep using both the facialdifferences and solid differences approach. In this case, if duringimport one fails, we will have a fallback.

Returning to the flow from box 536, if the operation that created thefeature was a modifying operation, then in step 540, a partial brep(e.g. a skin) is exported. According to one approach, the facialdifference technique is employed. Next, in step 548 a partial brep isattempted again, this time using a different approach. For instance, ifthe facial differences approach was used in step 540, then in step 548 asolid differences technique can be employed.

In step 552 another partial brep can be attempted, this time using stillanother approach. Here, for instance, the boundary differences techniquecan be employed.

If the decision boxes 520 and 536 did not create positive results, thenin step 556 feature is, for practical purposes, classified asirrelevant. Such a classification can be explicit or implied by the factthat nothing is done. Beyond failing the create and modify tests,characteristics of an irrelevant feature can include that the featuredoes not represent a geometric structure that has a brep.

For instance, a reference geometry feature, or a sketch feature does nothave a brep, so both would be classified as irrelevant features. Otherfeatures that can be classified as irrelevant features are those thatare not supported by the BPF fallback mechanism, and any of theprimitives discussed above. In the event that a feature is classified asan irrelevant feature the export process can terminate or move on to thenext feature.

Solid Differences

FIG. 6A is flowchart depicting a solid differences algorithm ortechnique, which can be a sub-process in the export algorithms. Theconcern with this algorithm is identifying the changes made to a solidby a feature and determining the brep for the changes (the feature)between the initial instantiation of the solid and the solid after thefeature is applied—i.e., a brep per feature.

To this end, in step 604 the processor executes steps to compute thesolid prior to the feature being applied. Let this solid be representedas S(A). In step 608, the processor executes steps to compute the solidafter the feature was applied. Let this solid be represented as S(B).

Next, in step 612 the algorithm causes the processor to subtract S(B)from S(A). The result is a solid, the solid being a Boolean differencebetween the two solids. This result, S(A−B), is represented as a brep.In step 614, the algorithm causes the processor to subtract S(A) fromS(B), which is again represented as a brep—S(B−A). In step 616 the brepsof S(A−B) and S(B−A) are exported, to be used later to build a breprepresentative of the feature.

Discussion of the complimentary import process is warranted here.Returning to FIG. 4, if the import action 468 exists for the featurethat created B from A, then the import action 468 will succeed and theimport algorithm 416 is done. However, if it does not, then thesimplifier module 462 is invoked and a rewrite 464 is attempted. If thefacial differences technique failed, then the solid differencestechnique is attempted. For instance two orphans can be used:orphan-add(S(B−A)) followed by orphan-cut(S(A−B)). The premise isA+(B−A)−(A−B)=B  EQ. 1.

Facial Differences

FIG. 6B is a flowchart depicting a facial differences algorithm ortechnique, which can be a sub-process in the export process.

In step 624, the set of faces in the solid with the feature, which donot appear in the solid prior to the feature, is computed. For instance,let F(A) be the set of faces in the solid prior to the feature and letF(B) be the set of faces in the solid after the feature. Applying aBoolean difference between the faces of A and the faces of B, that isF(B)−F(A), yields both the newly created faces and the modified faceslying on the preexisting surfaces of the solid. However, a geometricalgorithm can also be applied to compute the difference, such as aboundary difference algorithm.

One approach to computing the faces is to use a naming mechanism. Inthis approach, if the feature maintains a list of the faces that itcontributes to the current (but not the final) brep, then there is nowork to be done: the set of faces that do not appear is known. However,if a face was modified, then it might not appear in the namingmechanism. In such a circumstance, a superset of faces can be created,the superset including neighboring faces to the newly added faces sothat changes to prior faces can be detected.

In step 628, which is an optional but not a necessary step, a minimalset of faces is computed. Here, faces that lie completely on theboundary of the original solid are eliminated, because, referring to theconstraints on the sewing primitive, discussed above, they are notneeded. By employing this technique, it is possible to compact theresult and use less storage.

In step 632, the faces are stitched into connected components, or skins.One technique for stitching the faces into connected components is tointerrogate the topological structure of the brep.

In step 636 the brep representative of the skins is exported, and instep 640, the process returns to the algorithm that called it.

Boundary Differences

FIG. 6C is flowchart depicting a boundary differences algorithm, which,like the algorithms above, can be a sub-process in the exportalgorithms. The objective in this algorithm is to identify the changesmade to the boundary of a solid by a feature and determining the brepfor the changes (the feature) between the initial instantiation of thesolid and the solid after the feature is applied. (It is noted that anapplication for this algorithm is described and illustrated above withreference to the discussion of the sewing primitive and FIGS. 2F-G.)

In step 644 the processor executes steps to compute the boundary priorto the feature being applied. Let this boundary be represented as B(X).In step 648, the processor executes steps to compute the boundary afterthe feature was applied. Let this boundary be represented as B(Y).

Next, in step 652 the algorithm causes the processor to subtract B(Y)from B(X). The result is a skin, the skin being a Boolean differencebetween the two boundaries. This result, B(X−Y), is represented as abrep. In step 654, the algorithm causes the processor to subtract B(X)from B(Y), which is again represented as a brep—B(Y−X). In step 656 thebreps of B(Y−X) and B(X−Y) are exported.

As was the case in the solid differences algorithm, discussion of thecomplimentary import process here is warranted. Returning to FIG. 4, ifthe import action 468 exists for the feature that created B from A, thenthe import action 468 will succeed and the import algorithm 416 is done.However, if it does not, then the simplifier module 462 is invoked and arewrite 464 is attempted. If the facial differences technique or soliddifferences failed, then the boundary differences technique can beattempted. For instance two orphans can be used: orphan-add(B(Y−X))followed by orphan-cut(B(X−Y)). The premise, again, is found in EQ. 1(above).

Cad Specific Algorithms

The above description was a general, but specific, presentation on theBPF algorithms and systems. We note that in the process of implementingand experimenting with these algorithms on various types and versions ofCAD systems, some of our current and evolving implementations tune thesegeneral algorithms for the specific systems. These experiments have beenbuilt upon knowledge one of skill in the art would have with respect toa specific system and/or publicly available information, such as systemdocumentation or user support. These modifications are presented below.

For the CATIA system: Facial differences are calculated by (1)extracting the R-surfaces from the Catia primitive, (2) computing thebounding R-edges, (3) eliminating the R-edges that are on the boundaryof the solid that existed before the modifying operation was applied,(4) computing the R-surfaces that are adjacent to the remaining R-edges,and (5) extracting the skins from the connected components of theR-surfaces. We noted that step (3) is not required, since its primaryadvantage is reducing the size of the exported skin (i.e., a minimal setof faces). A geometric algorithm can be used in step (3).

For the I-Deas system: The entire brep exported for creating operationscan be extracted through a history tree. Each history tree has a featurenode, and the feature node has a feature model. The feature noderepresents a solid that is rooted at the featured node and defined bythe underlying sub-tree. The feature model contains the brep of thefeature node. Turning to facial differences, the naming mechanism heremakes use of the tracking ID feature in the I-Deas system. Here, we giveevery entity a tracking ID.

For the ProEngineer system: Because of the structure of the historytree, every creating operation, except the first, is a hybrid operation,thus the classification of creating operations is an exception here tothe normal classification methods. Thus, every creating operation isreally a unary operation that may globally modify the part. However, therepresentation of the feature includes information about the featureitself. Thus, the brep can be extracted from this self-encapsulated datadictionary in the feature. When constructing the brep from a ProEngineersystem, the surfaces of the feature should be searched to identify thosesurfaces that are active and those that are inactive.

For the UniGraphics system: an internal naming scheme identifies thefaces that were created by the feature. The naming scheme enables us toeasily identify and select faces affected by the feature.

We further note that the orphan-sew operation is handled by therespective systems as follows: in Catia, a sewing operation, inProEngineer and UniGraphics, a patch feature, in I-Deas, a projectcurve, delete faces, and join operations.

Import Algorithm

FIG. 7 depicts an import process, the import operating on the output ofthe export process. More particularly, FIG. 7 depicts the BPFsimplifiers that are applied during the import process if the featuresimplifiers fail or the corresponding import actions do not exist. It isnoted again that the BPF simplifiers, according to an embodiment,compliment the other CAD data exchange techniques references above.Thus, the BPF is a supplemental data representation of the exportedfeature in a situation where no fail occurred, and the fallback where afailure did occur.

In step 704, the feature from the export process is classified. Indecision box 708, the classification of the brep is analyzed todetermine if it is a single skin. If the brep is a single skin, then instep 712 an orphan of the skin is created using the orphan primitive,which is discussed above. In step 716, the orphan of the skin is sewn,using the sewing primitive, to the solid it operates on. The processcontinues to decision box 720 where a test is performed to determinewhether the operation was successful, if it was, then a success isreported in step 764, if not, then an error is reported in step 768.

If the feature is not a single skin, then in decision box 728, a test isperformed to determine whether the feature is a multi-skin. If thefeature is a multi-skin, then in step 728 one or more orphans arecreated using the orphan primitive. In step 732, a multi-sew operationis performed on the skins. Alternatively, multiple single sewingprimitives can be performed. The process continues to decision box 720,which is described above.

If the feature is not a single-skin or multi-skin, then in decision box736, a test is performed to determine whether the feature is a solid. Ifthe feature is a solid, then in step 740 an orphan is created, and instep 744 a Boolean operation is used to combine the orphan to theearlier object. Again, processing continues to step 720.

If the feature is not a solid, then in decision box 748, a test isperformed to determine whether the feature is a multi-solid. If thefeature is a multi-solid, then in step 752, an orphan is created, and instep 756, a Boolean operation is performed. (It is noted that thisprocess is analogous to the multi-skin classification.) And again,processing continues to step 720.

If the feature was not a multi-solid, then in step 760 an error isreported and the process terminates.

It should be appreciated that the brep per feature methods and systemsset forth above are computer implemented. As such, the methods can bedistributed among multiple processors, or they can be broken up intocomponent parts of an overall computer software product or system. Insuch an embodiment, the computer software product is typically embodiedin executable object code, or interpreted source code, that is loadedfrom a persistent memory to a temporary memory just prior to executionby a processor.

According to one embodiment of the methods and systems described herein,there is a logical and physical partitioning between the export andimport aspects of the systems. For instance, aspects of the computersoftware product can be a plug-in to an existing computer aided designsystem software that is resident on a first computer, such as all of theexport methodologies, while other aspects are a plug-in to a second,differing computer aided design system software that is resident on asecond computer. Furthermore, it is noted that common nomenclature fordifferent operations is used. The objective of these operations is clearfrom the description provided, but it should be appreciated thatdifferent CAD systems may use different terminology or a slightlydifferent technique (for example “sewing” may effectively be “patching”or “stitching” or some other function name in different CAD systems).

Furthermore, aspects of the methods and systems can be common to boththe first and second computer. Or, in yet other embodiments, thecomputer software product embodying the methods can be combined into asingle computer system acting in a client/server relationship withsource and target CAD systems, or as middleware that bridges and/ormanages the CAD data exchange processes between such CAD systems.

Complimentary Techniques

Above it is mentioned that the brep per feature and associatedtechniques and systems described herein can be independent andcomplementary of CAD data exchange techniques. Furthermore, in somecircumstances, the brep per feature techniques can be strictly dependentupon the failure of some other export or import technique as a designmodel is extracted from a source CAD model and imported into a targetCAD model.

While some of these techniques are described in earlier filed patentapplications, which are incorporated herein by reference in theirentirety above, certain subject matter is repeated again below,understanding now that these same steps can be complimented by the brepper feature techniques, or the brep per feature techniques can be usedas a fallback mechanism in the event one of the earlier techniques fail.

Cad Data Exchange Failure

Turning to FIG. 8, it is a flow diagram that shows various CAD dataexchange techniques and subsequent failures that can trigger the BPFtechniques set forth above. It is again noted here that BPF is shown asa fallback mechanism, as the BPF is invoked after step 838 (likewiseafter step 841)—that is, when a failure occurs, at step 843.

In step 831, a test is shown that determines whether the failuredetection is initialized based upon an API call, or some other operation(e.g., pattern matching, function mapping, user emulation, or brep). Ifthe failure detection process follows an API call, then in step 832 theintermediary system waits for a signal back from the API that isindicative of success or failure of the API call. Otherwise, the processcontinues to step 834.

In step 833, a test is performed to determine whether the API failed. Ifthe API did fail, then a fail signal is returned to the data exchangeprocess in step 838 and BPF is invoked at step 843. If not, then step834 is performed, which also follows step 831. In step 834, a physicaland/or geometric property analysis is undertaken wherein geometricand/or physical properties of the source CAD model are compared with thetarget CAD model. For instance, a surface area calculation can beperformed, a mass or density calculation can be performed, and/or a lineor perimeter calculation can be performed. Other solid or geometricmodeling calculations can be performed too.

In step 835, the result of the comparison in step 834 is tested againstaccepted tolerances associated with the target CAD system. It is worthnoting that the tolerances can not only be with respect to the sourceand target CAD model properties, but also just the target CAD objectproperties with respect to design or feature tolerances correspondingstrictly to the target CAD system. If the result is within the toleranceof the target CAD system, then the process continues to step 839, whichis described below. Otherwise, the process continues to step 836, wherethe target feature is adjusted.

For instance, with respect to adjusting the target feature, if it isdetected that two lines do not meet in the target CAD object, one orboth of the two lines can be extended towards the other in an attempt tocreate an intersection between the two lines. In step 837, thetolerances can again be tested, as is described above. However, if thetest fails, then a failure notification is returned to the data exchangeprocess in step 838 and BPF is invoked at step 843.

If the test succeeds in step 837, then in step 839 undo information canbe persistently stored in memory so that, if needed, the creationprocess can be undone. In practice, what is saved in the undoinformation is a synchronization point or marker for the source CADmodel, as well as the corresponding operations for the target CAD model.

For example, assume a particular source CAD model has three features.When exchanging the source CAD model to the target CAD model, the firsttwo features are successfully transferred, but the third fails. It ispossible that the third feature exchange was not, in fact, a failure;rather the first or second feature exchange caused the third featureexchange to fail. In such a circumstance, when adjusting the particulartarget CAD feature (itself) does not successfully reproduce the sourceCAD feature and/or when the BPF technique fails, it is possible toback-out the second feature and then repeat the second feature exchangewith a new technique. If adjusting the second feature exchange does notachieve a successful operation for the third feature exchange, then thefirst feature can be backed-out with the undo information.

In step 840, a “success” signal is returned to the main CAD dataexchange process. While not an explicit step in the failure detectionprocess, note 841 shows that a subsequent operation may identify afailure from a previous operation. In such an instance, the undoinformation saved in step 839 can be used to undo the previousoperation—and any subsequent operations to the previous operation.

Pattern Matching

Turning to FIG. 18, it depicts an operational overview of a patternmatching technique. A volatile memory region 1803 of a computer systemholds portions of data from a persistent memory associated with, forinstance, database 1802 and/or source CAD system 1801, which canpartially reside on one or more persistent magnetic or optical storagedevices.

The volatile memory region 1803 comprises four sections of memory. Amatch data region 1804 temporarily caches static match data that is partof the system knowledge base. The match data is a subset of theknowledge base that is a region of interest, or of higher statisticalprobability for finding a known pattern. A current object region 1805temporarily caches one or more portions of a feature list from a sourceCAD system 1801—this cache generally represents a set of data (oroperations) that is sufficiently proportioned so that it is large enoughto hold the largest source operation pattern.

Regions 1804 and 1805 are used primarily to reduce I/O and associateddisk access latencies. The regions can be of variable size, and,according to one embodiment, the memory 1803 can further include a hashor index to expedite searches in larger record sets, or at least recordsets that are beyond the bounds of the data stored in memory 1803.

A current feature region 1806 is smaller than the match data region1801. The current feature region 1806 holds the source operation, drawnfrom the current object region 1805 that is the basis of a query of thematch data region 1801.

The current match region 1807 temporarily stores match data records,i.e., information from the records of the knowledge base 1802 thatindicate how the target CAD system is to construct the target CADmodel—or the target feature. The current match region 1807 can be small,but if it is small, then the region should be frequently written to apersistent memory region and then flushed. Of course, if the region islarge, the same is true, but the frequency could be decreased.

Although optional, a bridge or temporary structure 1802′ is shown inFIG. 18. The bridge structure 1802′ can be similar or equivalent to theUPR described above with reference to FIG. 4 (element 451). Thus, thebridge structure 1802′ can include additional information concerning thesource CAD model, the target CAD model, and extraction and creationinformation that can be used for a lossless, two-way data exchange. Forexample, it may include a data dictionary with redo or undo information,feature and/or representation associations, sequence or order ofoperation information, and other system information.

FIG. 19 depicts exemplary data structures for the knowledge baseembodied in database 1802. According to one embodiment, the datastructure comprises a conversion table 1908 having a source CAD systemtype and a target CAD system type. Matching the source and target CADsystem types, a computer executing the steps of the invention can accessa pointer to additional records or data structures that correspond tothe particular CAD data exchange desired. While X's are shown forconversions of similar CAD types, the methods of the invention areequally applicable to conversions of CAD models of similar types, buthaving different versions. Thus, converting a CAD model from aProEngineer Version 2000i2 to a ProEngineer Version 2000i, i.e., abackward conversion, is possible, as is a forward conversion (2000i to2000i2). Pointers to match data records for the various version numberscan be included in the structure too.

According to another embodiment, a conversion table 1908 is notnecessary. For instance, the CAD data exchange software is typicallyembodied in a plug-in to a third-party CAD system. The plug-in can beconversion specific, meaning that the plug in only converts files oftype A to files of type B (and vice versa). In such an instance, theconversion table 1908 information is already known, thus the table 1908is not necessary.

In an aspect of the pattern matching technique, match data records 1909are used to effectuate the pattern (or even the function) matchingprocess. The match data records 1909 include two areas. The first area1910 stores source function or operation information. The sourcefunction information corresponds to one or more operations or geometricstructures in the source CAD system. The second area 1911 stores targetfunction information or geometric structures for the target CADsystem—for instance, a pointer to a function that does the desiredaction. The target function information corresponds to one or moreoperations in the target CAD system—for instance, the target functioninformation can include a function or pointer to a function for the APItechnique 436. An end of file area 1912 can also be included so thatmatch data records 1909 are easily identifiable from one another, as itis possible that the records have a variable length. However, if fixedlength match data records 1909 are used, then the end of file area 1912is unnecessary.

Additional data structures can also be included. For instance, as wasmentioned above with reference to FIG. 18, the match data records 1909can be broken into various hash buckets by using known hashingtechniques, or a B-tree or other type of indexing structure can be usedto expedite search operations. Moreover, it can be efficient to sort thematch data records 1909 prior to run-time or once the records have beenupdated. If the records are sorted then regions of memory with a highlocality of reference (meaning that if a memory address X is called,then memory address Y is likely to be called too) can be groupedtogether, thereby reducing I/O and read latencies.

FIG. 20 is a flowchart detailing a method for pattern matching asapplied to CAD data exchange. It is convenient, but not necessary, toreview FIG. 20 with reference to FIGS. 18 and 19. For purposes of thisexplanation, it will be assumed that the relevant portions of the sourceCAD model 1801 and the knowledge base 1802 have been read into memory1803.

In step 2001, a current feature from the source feature list is read andloaded into a the current feature region 1806. In step 2002, the data inthe current feature region 1806 is compared against source functions1910 in the match data region 1801 by searching the region 1806 for amatching data record. In step 2003, if a match was found, then theprocess continues to step 2005, otherwise a fail signal is returned tothe main CAD data exchange algorithm.

In step 2005, information corresponding to the current match data record1909 is saved in the current-match region 1807. The information can becurrent match record 1909 itself, a pointer the current match record1909 in the knowledge base 1802 or match data region 1801, the targetfunctions 1911, or the target functions 1911 translated with anysupporting data (e.g., parameters for the target CAD system, and/oradditional information concerning the extraction or creation process).

In step 2006, a test is performed to ensure that there are no additionalfunctions in the source feature that need to be exchanged. If additionalfunctions need to be processed, then the method continues to step 2007.Otherwise, in step 2012 the current match record 1909 can bepersistently saved (if not already) and the next function correspondingto the feature can be loaded in step 2007 such that the search (2008)and match (2009) steps can be performed.

In step 2009, it is possible the additional function(s) added to thesearch created an incompatible match. In step 2013, this scenario ishandled. According to one embodiment, any changes made or added to thetarget feature list are backed-out on feature by feature basis (step2014). One reason this process may be implemented is that a subsequentattempt to handle the failed operation(s) may more efficiently model aseries of operations (e.g., an entire feature) rather than a singleoperation. In another embodiment, the last saved match data record isused as the basis for the target feature list (step 2015), and theremaining functions can be exchanged with the target CAD system via analternative method. In step 2016, the match data record information isentered for the target CAD model.

Returning to step 2009, if a match is found, then in step 2010information corresponding to the match data record 1909 is saved. Ifthere are more operations in the source CAD model at step 2011, thenprocessing returns to step 2007. Otherwise, the saved target functionlist, which can comprise multiple sets of information corresponding totarget functions 1911, is entered into the target CAD model in step2012.

It is worth noting that while the pattern matching process describedabove is defined with reference to a particular feature, which is thepreferred embodiment, it, is possible to perform the pattern matchingwith respect to individual functions without regard to their overallrelationship to a particular feature.

According to one embodiment, after a particular feature is created usingthe pattern matching technique, then a physical and/or geometricproperty analysis (as is discussed above) is performed on the targetfeature and the properties are compared against physical/geometricproperties of the source feature. If the properties do not match, thenthe parameters of the target feature list can be adjusted until theproperties are within an acceptable tolerance.

User Emulation

FIGS. 9A-C depict aspects of user emulation, which is a fallback oralternative technique used to perform the extraction and creationprocesses. According to one embodiment, the user emulation techniquesare used to directly exchange data from the source CAD system to thetarget CAD system. Alternatively, the user emulation techniques can beused to exchange data from the source CAD system to the target CADsystem through an intermediate file, such as the bridge data structure.In still another embodiment, the user emulation techniques are used togather information on either the source CAD model or the target CADmodel.

For instance, the user emulation techniques described below can be usedto collect attributes or callout information corresponding to a sourceor target feature, to perform geometric or physical property analyses,or to select a particular edge or face on the source or target CADmodel. In still other embodiment, the user emulation techniques can beused to automate a process with a known user interface behavior.

Turning to FIG. 9A, it is an architectural overview of an embodiment ofthe user emulation techniques. The figure is useful in understanding howthe different software modules of a programmed computer interact.

CAD system software 901 includes a user interface. The user interfacetypically interacts with a user through a pointing device, such as amouse, or keyboard controls. For purposes of this explanation, the mouseand keyboard controls will be called “interface inputs”. In fact,however, the user interface does not directly interact with theinterface inputs. In practice, interface inputs are passed through adevice driver (not shown) and presented on a computer monitor (notshown). At the same time, information corresponding to the interfaceinputs are passed through, for instance, an X-server 902 to the CADsystem 901. The user interface of the CAD system 901 in turn can respondto the interface inputs by sending data or commands back through theX-server 902, which are then output to the computer monitor.

It is noted that an X-server is only an exemplary graphical windowingmodule. Under certain operating systems, the role of the X-server isperformed by other graphic images servers or modules. These modules caninclude, for instance, the USER.EXE and GDI.EXE executables in MicrosoftWindows NT. In other environments additional executed or interpretedmodules, such as interfaces created in Java Script or using various Javaclasses, could perform a similar functionality for the application oroperating environment.

For example, a user may move a cursor (with a mouse) from position (x1,y1) to (x2, y2) and then performs a mouse click. The mouse sends theinterface inputs to a device driver, which translates the movement intoelectrical signals. The interface inputs are sent to the X-server 902,which controls a bitmap display for the monitor. Electrical signals arealso sent to the CAD system 901. The CAD system 901 receives theinterface inputs and determines how the CAD software should respond (orchange) to the interface inputs. The response can include changing thecolor of a particular menu item, presenting menu pull-down list, orselecting a feature of a particular object. Once the CAD system 901determines how the display should change, the CAD software makes thecorresponding state change internally and then sends additionalinformation back to the X-server 902 so that the computer display can bechanged appropriately.

According to an embodiment, the user interface does not interact withthe X-server 902 directly. Instead, the user interface interacts withone or more software modules, at least one of which is emulating a user.A proxy 903 acts as a buffer between the CAD system 901 (and its userinterface) and the X-server 902. Signals passing through the proxy 903are passed off to an interpreter 904, which examines the signals andemulates a user response. The emulated user response can be sent backthrough the proxy 903 to the user interface or to the X-server 902. (Itis worth noting that the proxy 903 and the interpreter 904 can beresident in a single software module, for instance a plug-in that iscoupled through the CAD system 901.)

In an alternative embodiment, data and control signals between X-server902 and the CAD system 901 can be captured by a plug-in to the CADsoftware. In responding to the captured signals, the plug-in can enter astate that is essentially a time delay. A second, sub-thread can then bespawned by the plug-in that processes the captured signals. Once theplug-in has processed the signals, it can store state information (inreserved memory associated with the plug-in) corresponding to the CADsystem and signal the plug-in to terminate the wait state.

Meanwhile, the CAD system returns to normal processing under theassumption that the plug-in has terminated. The next time the signalsare captured by the plug-in, the plug-in can again instruct the CADsystem to invoke the plug-in and then resume processing in thesub-thread—picking up the process where it left off. While thistechnique may not be thread safe, it is a useful method for executingtwo processes that are, in a normal operating environment, mutuallyexclusive.

According to one embodiment, before terminating the plug-in, thesub-thread initializes a timer. The timer can be used to detect when anexternal processing error occurs. If the timer expires before processingthe state information by the sub-thread is resumed, then an errormessage can be returned so that the user emulation process can becanceled or backed-out.

According to an embodiment, the underlying CAD system, C libraryimplementation, or platform does not allow safe cross-thread calls. Towork around this prohibition, when the sub-thread needs to directly callthe CAD) system API, the sub-thread uses inter-process communication,remote procedure calls, or cross-thread messaging techniques to pass arequest to the plug-in to perform the call on the sub-thread's behalf.

FIG. 9B is a screen shot 905 detailing aspects of a selecting an object,which is one useful process to which the user emulation techniques canbe applied. In an environment, the screen includes a tool bar 912, whichhas text based menu options, a major view 910 of the object (here acube), and a zoomed view 909 of a portion of the object. The zoomed view909 further includes a button bar 908, which has mouse selectableoptions that are typically used for specifying to the CAD system whethera particular feature of the object has been selected. Also shown in thescreen shot 905 is a status indicator 906 and a coordinate indicator907, the coordinate indicator 907 showing a present position of thecursor 913. A graphic element, here an edge 911, of the object is shownhighlighted. (As used herein, the term “graphic element” refers to aline, edge, face, surface, or other graphical design feature of the CADobject—usually in two- or three-dimensional form, that is presented fora computer display.)

FIG. 9C is a diagram of an exemplary signal from the X-server 902. Inthis instance, the signal can be a color indicator for a particulargraphical element shown in the windowing system. According to anembodiment, an act of selecting a graphical element on the objectinvolves monitoring one or more signals from the X-server 902 for astate transition in a color indictor associated with one of the buttonsin the button bar 908, or the status indicator 906. Detecting the statetransition of an indicator can implicitly indicate that a user emulationprocess did not fail.

For instance, the X-window text in the status indicator 906 may changecolors depending on whether the system is waiting for a user response orprocessing a previous response. Another option is to scan text fordialogue boxes or pop-up windows for words indicative of a failure orsuccess of a previous operation.

FIGS. 10A-D are flowcharts detailing steps for the user emulationtechniques. The user emulation techniques are typically performed by theinterpreter 904 in combination with other elements of a computer system.

Turning first to FIG. 10A, it depicts the primary steps for useremulation. In step 1001, setup operations are performed so that theinterpreter 904 can be calibrated to the windowing system. In step 1002,a graphic element shown in windowing system is selected.

In step 1003, a test is performed to verify that the correct (ordesired) graphic element is selected. For instances, selecting andverifying the graphic element can involve stepping through a featurelist in a CAD model and monitoring a signal from the X-server 902.Alternatively, emulated mouse movements and clicks can be sent to theX-server 902 and the resulting status signals returned to the CAD system901 can be monitored for state transitions, or text strings.

Once the correct graphic element is selected, then an operation isperformed on the graphic element in step 1004. The operation can beperforming a property analysis, reading attributes corresponding to thegraphic element, hiding or suppressing the graphic element, initiatingan export command (e.g. creating a brep), or modifying attributescorresponding to the graphic element. In step 1005, a test is performedto determine whether the operation failed. If the operation failed, thenthe next CAD data exchange method is attempted, otherwise the exchangemethod can be considered successful.

FIG. 10B is a flowchart depicting steps for performing the setupoperations. In step 1007, the windows shown in the display device areidentified. Window identification is based on any or all of thefollowing, depending on the specific CAD system involved: (1) the windowhierarchy (e.g., the number of child windows, the position of thevarious windows in the window list); (2) any text string displayed inthe windows; and/or (3) the geometry of the windows (e.g., their width,height, ratio of width to height, position on the screen). The windowscan be stored in memory with identifiers selected by the CAD dataexchange software, or they can be stored with identifiers correspondingto text associated with the window (e.g., a title or header). Next, instep 1008, signals corresponding to movements of the cursor (e.g. 913)are calibrated to the coordinates of the windowing system (e.g. 907).The calibration is saved in memory so that adjustments or translationscan be made to signals generated by the interpreter so that the signalsare tuned (e.g. scaled) to the particular windowing environment andpointing device settings.

In step 1009, a menu mapping is performed. Generally, the menu mappinginvolves reading the text of the main tool bar 912 options, sending amouse click to each option and further mapping the sub-options. Theresults of the mapping are also stored in memory so that they can bealigned with future operations that are to be performed, such as if useremulation is used as part of the pattern matching techniques. The menumapping can also be used to verify the (national) language or version ofthe CAD software.

FIG. 10C is a flowchart depicting steps for selecting a graphic element.The steps are particularly related to selecting a feature or aspect ofan object presented in a window, rather than an option from main toolbar 912 or one of its sub-options.

In step 1010, a test is performed to verify that the graphic element isvisible in the target window. If the graphic element is not in thetarget window, then the window positioning or vantage point can beadjusted, for instance by using the main tool bar 912. In step 1011, oneor more features other than the desired feature (e.g. those featuresdirectly adjacent to or near the desired feature) are hidden orsuppressed. In an alternative embodiment, the one or more features aredeleted, but only where they can be recovered later. Next, in step 1012,a region of the target window is zoomed out (making the object smaller),and in step 1013, the window is centered about the target graphicelement. In step 1014, a mouse click is sent to the center of the targetwindow.

Turning to FIG. 10D, it is a flowchart depicting a technique forverifying that the right element is selected. In step 1016, a returnstring or state indicator from the X-server 902 is checked to verifythat the correct graphic element was selected. According to oneembodiment, if the correct graphic element, or any selection was notdetected, then the process continues to step 1012 (or step 1002) so thatthe target window can be re-centered about another point and/or the zoomfactor can be decreased (making the object larger):

However, as is depicted in step 1017, if a failure is detected, thenuser emulation is canceled and processing continues to the next CAD dataexchange technique. If a failure is not detected, then state informationcorresponding to the CAD object prior to any changes made by the useremulation process is persistently saved in step 1019.

Step 1020 shows a test for a failure of a subsequent operation, forinstance in an operation that occurred outside of a user emulationtechnique—an API, a pattern matching, a later user emulation, or a brepprocess—when handling the CAD data object. If the subsequent operationfailed, then it is possible that the user emulation from the previousoperation was in fact a failure even though no immediate failure wasdetected (e.g. from a property analysis). Thus, in step 1022, the stateinformation stored in step 1019 is backed out (e.g. a rollback process)from the CAD data model. If the subsequent operation did not fail, thenin step 1021 the state information is deleted.

Edge Selection

Part of the CAD, data exchange process can involve performing operationsthat require identification of some part or feature of a defined CADmodel. To this end, the edge selection techniques described belowprovide a new and useful tool that can be used when performing suchoperations—the techniques are used for the purpose of correlating sourceedges to target edges in a plurality of computer aided design systems.For instance, the operations can include a round or chamfer operation ona target CAD model, or selecting a face of an object. The process can bea stand-alone process, the process can integrate steps from the useremulation process (described above), or the process can be integratedinto the user emulation process. Furthermore, it is noted that in theaccompanying figures and description, abstractions of lines and shapesare used, as they might appear to they eye, even though what is actuallyoperated on and used in the techniques are data representations of linesand shapes.

FIGS. 11A-D illustrate the current problem. FIG. 11A depicts a3-dimensional object 1101 in a source CAD system. The object has asomewhat rounded side that is represented by four faces (only face 1105and 1106 are called out). An edge 1102 represents a curve formed by thefour faces. A round operation is specified in the source CAD model, theoperation being performed on the edge 1102. Referring to FIG. 11B, whenthe round operation is performed, a rounded edge 1104 is formed wherethe edge 1102 once existed. The object 1101 is now shown as object1101′.

As is mentioned above, an underlying object of the CAD data exchangetechniques is that the design intent from the source CAD model ispreserved in the target CAD model. Accordingly, in some instances, finergranularity representations of source CAD model are often found intarget CAD models, while in other circumstances, the oppositerelationship exists. FIGS. 11C-D show such a finer granularityrepresentation of the source CAD model as embodied in the target CADsystem. For instance, in object 1103, the four faces that comprise edge1102 in object 1101, now consist of eight faces, which include faces1107, 1108, 1109 and 1110 and now make edge 1102′. What is desired is tocorrelate the edge 1102 with the edge 1102′ so that the feature 1104 canbe created in the target CAD system as feature 1104′.

FIG. 12 depicts an operational overview of the edge selection algorithm.An object (e.g., a boundary representation of a block) exists in thesource CAD system 1202, the object having an edge “a”. Edge “a” isexported to a global scene 1210 for the data exchange product by anexporter module 1208. Once the edge “a” has been identified in theglobal scene 1210, the importer module 1206 must now identify thecorresponding edge in the target CAD system 1204. A local scene 1212 isthen exported from the target CAD system, the local scene representing aplurality of candidate “edges” that may match edge “a”. It is noted herethat the local scene 1212 is exported in an incremental manner. While itis possible that the entire local scene 1212 may be exported at once,generally, this is not the case, which is noted by the circular dataflow noted in FIG. 12.

Once the local scene 1212 (or a portion thereof) is exported, then theedge selector module 1207 begins the correlation process. Edges in thetarget CAD system 1204 that are unnecessary are removed from candidacy,while a mapping is maintained of the others, the mapping ideallyrepresenting an n:m, where n is greater than or equal to m,correspondence between the target CAD system 1204 edges and the sourceCAD system 1202 edges. Since the mapping is maintained, subsequentoperations on edge “a” can be identified as applying to edges “b1” and“b2”. Following are multiple techniques that can be used independentlyor in combination for selecting an edge.

Edge Overlap Algorithm

The underlying premise of the edge overlap algorithm is that two edges(i.e., from a source CAD model and a target CAD model—the global andlocal scene) overlap if their intersection is topologically onedimensional (“1-D”). If the two edges overlap, then they lie on the samegeometric carrier.

In one embodiment, the geometry of an edge is represented as anon-uniform rational B-spline (“NURBS”). Making a NURBS representationof the geometry of the edge gives each edge a start-point and anend-point. If the edge is closed (i.e., a circle) then the start-pointand end-point coincide. While start-points and end-points are usedaccording to one embodiment, it is also acceptable to use start- andend-vertices. Other embodiments of the invention are envisioned, thusanother representation of an edge can also be discrete linear segmentswith corresponding Cartesian coordinates.

Turning to FIG. 13, it is a flowchart depicting the edge overlapalgorithm. In step 1302, the start- and end-points of the NURBSrepresenting each edge are extracted from the NURBS.

In step 1304, regions are determined in, for instance, the source edge.The regions represent the number of times the source edge is divided ifthe target edge start- and end-points are mapped onto it. Thus, if asingle point in the target edge is found in the source edge, then thesource edge has two regions. However, if two points in the target edgeare found in the source edge, then the source edge has three regions. Itis useful in step 1304 to sort the extracted points—the regions of thesource edge are between every consecutive pair of distinct (sorted)points.

FIG. 14 illustrates an example of determining regions of a source edge.A source edge “E” (1402) and three candidates 1404 for target edges “F1”(1406), “F2” (1408), and “F3” (1410) are depicted. Determining theregions of source edge E vis-a-vis the various target edge candidates1404: E has one region with respect to F1; E has two regions withrespect to F2; and E has 3 regions with respect to F3. When identifyingthe regions, it is noted that the source edge always has at least oneregion but no more than three regions.

Returning to FIG. 13, in step 1308, a region containment operation isperformed. The region containment algorithm, of which step 1308 is apart, assumes that the source edge and the target edge have the samegeometric carrier. The region containment operation selects the midpointof a region defined by the source edge. In step 1310, a test isperformed to determine whether the selected midpoint is within thetarget edge. In step 1312, if the selected midpoint is within the targetedge, then the source and target edges are said to overlap and theresult is returned. If the midpoint is not within the target edge, thenno overlap is assumed to exist, an appropriate response is returned instep 1314.

It is noted that the above process does not require laser-likeprecision. It is appreciated by the inventors that different CAD systemsmay represent a non-linear segment in different ways. It is not theobjective of the CAD data exchange system to re-create source CAD modelsexactly the same way in a target CAD model—that is, with the sameunderlying know-how. Rather, it is the objective to create an acceptabletarget CAD model that respects the know-how of the source and target CADsystems. Thus, tolerance in determining whether a particular point onthe source edge or target edge lies in the other is designed into theanalysis. Accordingly, mathematical or statistical analyses can be usedto model such a tolerance, or the tolerance can be hard-coded into theCAD data exchange system.

Edge Containment Algorithm

While the granularity of the target CAD model is ideally the same orfiner than the source CAD model, it is possible that the target CADmodel represents a particular edge in a manner that is more efficientthan the source CAD model. In such a circumstance it is useful toperform an edge containment algorithm (as opposed to the regioncontainment operations) to verify that all of the regions of the sourceedge are contained in the target edge. It is further noted that thisprocess can be used to verify the overlap of two edges even though thetarget edge is represented in a finer granularity than the source edge.

As was the case with the edge overlap example, the source and targetedges can be utilized from the global and local scenes (depicted in FIG.12). Depending on the verification desired (i.e., the target edge hasmore representative regions than the source edge or vice-versa), theinput to the edge containment algorithm can be selected according to thedesired output. Furthermore, the edge containment algorithm can be usedin conjunction with the edge overlap algorithm, which is describedabove.

Here, for the purpose of explanation, it is assumed that the target edgehas more representative regions than the source edge, as was the caseabove with reference to FIGS. 11A-D. Additionally, when a set of targetedges overlap with a source edge “e”, this set of target edges will bereferred to as a “connected” set. Furthermore, a sequence of orientededges, such that the end-point of each oriented edge is the startingpoint of its successor, will be referred to as a “chain”.

Turning to FIG. 15, it is a flowchart of the edge containment algorithm.In step 1502, a sequence of memory locations representative of a chainof target edges (“C”) is flushed. In step 1504, a first target edge islocated, preferably from the local scene, and added to the set “C”. FIG.16, which is described below, depicts an embodiment of one algorithm forfinding the first target edge. According to another embodiment, thesystem searches for an edge within a given proximity of a source edge“e”.

In step 1506, a test is performed to determine whether a target edge wasfound and whether the target edge overlaps the source edge “e”. If notarget edge was found, or the edges do not overlap, then the target edgeis removed from candidacy as a matching edge in step 1522. Otherwise, instep 1508 the target edge is extended forward to encompass a next,connected edge. In step 1510, a test is performed to determine whetherthe newly extended edge is contained by the source edge “e”. In step1512, if the newly extended edge is contained by the source edge “e”,then the next, connected edge (extended above) is appended to the targetedge and saved in the chain of edges “C”. The process repeats until thetarget edge can be extended forward no longer.

In step 1514, the same process that was described above with referenceto steps 1508-1512 is performed, but here, the target edge is extendedbackward in steps 1514, 1516, and 1518. Moreover, if the extended edgeis not contained by the source .edge “e”, then processing continues tostep 1520.

It is noted that one embodiment of the edge extension process, which isdepicted in steps 1508, 1510 and 1512, as well as steps 1514, 1516, and1518, is described in below with reference to FIG. 17.

In step 1520, the chain of edges “C” is returned as the target edgesthat matches the source edge.

Finding an Initial Edge

Turning to FIG. 16, it depicts an embodiment of a computer implementedmethod for finding the initial edge for the edge containment algorithm.In step 1602, a point “p” is selected from the source edge “e”. The “p”can be an interior point of “e”, or it can be a start-or end-point. Instep 1604, a set of edges “F” (e.g., from the local scene) is createdthat contains the point “p”. (It is noted that the set of edges “F” mayhave already existed in the local scene, but additional members of theset “F” can be added at step 1604—since the creation of the local sceneis an incremental process.)

In step 1606, non-overlapping edges in set “F” are removed from set “F”.Generally, each edge in set “F” can be iteratively tested against thesource edge “e” to verify, that the two edges overlap.

In step 1608, a test is performed to determine whether the set “F” isempty. If the set “F” is empty, then an error has occurred, as isindicated in step 1614. If the set “F” is not empty, then in step 1610 atest is performed to determine whether the set “F” holds more than 2target edges. If the set “F” holds more than two target edges, then anerror has occurred, as is indicated in step 1614. If, however, the set“F” comprises one or two target edges, then one edge is returned forprocessing in step 1612. (The second edge can be processed if thereturned edge does not sufficiently overlap the source edge “e”.)

It is noted that step 1614 can involve one or more error correctionschemes whereby the particular error correction scheme selected may havean effect on steps 1608, 1610, and/or 1612. Those schemes can includeselecting a new point “p”, or selecting a second point “p”′—the secondpoint “p”′ being close to point “p”.

It is noted that FIG. 16 can short circuit the remainder of stepsdepicted in FIG. 15 if, for instance, a single target edge is identifiedthat completely contains (and is itself completely contained by) thesource edge.

Chain Extension Algorithm

Turning to FIG. 17, it depicts a computer implemented process forextending a chain of edges (“C”) representing the source edge “e”according to an embodiment of the invention. The method can be used as asubstitute for the process described above with reference to FIG. 15(steps 1508, 1510, and 1512, or steps 1514, 1516, and 1518), or anadjunct to the process. Moreover, the chain extension algorithm can beapplied equally to the process of extending a chain of edges forward orbackward.

In step 1702, a member of the set of edges, i.e., the chain of edges“C”, is made the last edge in the set. For purposes of explanation, thisedge will be referred to as edge “c”. In step 1704, a set of targetedges adjacent to an end of “c” is identified. This set of adjacentedges will be referred to as set “F”. In step 1706, edges in set “F”that do not overlap the source edge “e” are eliminated—in accordancewith any of the overlap or containment processes described above.

In step 1708, a test is performed to determine whether the set “F” isempty. When “F” is empty, then the algorithm proceeds to step 1718. Ifthe set “F” is not empty, then in step 1710 a test is performed todetermine whether the set “F” includes more than one target edge. Ifstep 1710 results in a response indicative a set of “F” that is greaterthan one, then an error has occurred and step 1716 is performed. Step1716 can include returning a failure result, or indicating that a newedge “c” should be selected, or the existing edge “c” should be extendedanother direction.

However, if there is exactly one edge adjacent to target edge “c”, thenthe one edge (edge “f”) is appended to the set “C” in step 1712. In step1714, edge “f” is tested to determine whether it is the first edge inthe set C (i.e., there are no more adjacent edges that are not membersof set “C”). If edge “f” is not the first edge in set “C”, then in step1720, edge “f” is set as edge “c”, and the process continues to step1704. Otherwise, in step 1718, set “C” is turned and the process iscompleted.

Finally, it is noted that it may be desired to repeat the above processin another direction—as the process described above was only withreference to a single direction of extension, as is indicated in therepresentative embodiment described above with reference to FIG. 15.

Computer Program Product

The techniques described above beginning at CAD DATA EXCHANGE FAILURE,as well the BPF techniques described above said section, are intended tobe embodied as one or more sequences of instructions, that is a computersoftware or computer program product—such as information burned onto aCD-ROM or stored in an electromagnetic memory device, that cause one ormore processors or technical systems to perform the methods andtransformations described herein. The computer software product cancomprise executed object instructions and interpreted program code, orvarious scripting languages. For instance, the BPF techniques can beembodied in one computer software product, while the API, useremulation, pattern matching, and brep techniques embodied in one or moreadditional computer software products.

The computer software product can run on a stand-alone computer, forinstance a computer system running Microsoft Windows NT (TM), and is anplug-in to an existing computer aided design system, such as ProEngineer2000i2 (TM). However, in other embodiments, the processes can beseparated in functionality. For instance, the extraction or exportprocesses can run on a first computer system, while the creation orimport processes can run on a second computer system. Further still, inanother embodiment, a middleware system, operating in a server fashion(of a client-server system), can perform the processes eitherstand-alone (of course, using the APIs on either of two client systems),or as an intermediary between the various processes.

1. A computer implemented method for creating a boundary representationon a per feature basis from a parametric design model, comprising:loading the parametric design model from a source CAD system, the designmodel including a plurality of features; classifying a first featurefrom the plurality of features using a knowledge base to determine atype of operation that created the first feature; creating anon-parametric boundary representation from the first feature, based onthe step of classifying, until the non-parametric boundaryrepresentation is inclusive of the first feature; storing saidnon-parametric boundary representation in a memory; and repeating theacts of classifying, creating, and storing for each additional featuresfrom the plurality of features.
 2. The method of claim 1, furthercomprising: creating a parametric representation of the first featureassociating the parametric representation of the first feature with thenon-parametric boundary representation of the first feature; andrepeating the acts of creating the parametric representation andassociating for additional features from the plurality of features. 3.The method of claim 2, wherein the act of creating the parametricrepresentation of the first feature comprises performing an applicationprogramming interface technique.
 4. The method of claim 2, wherein theact of creating a parametric representation of the first featurecomprises a pattern matching technique.
 5. The method of claim 2,wherein the act of creating a parametric representation of the firstfeature comprises a user emulation technique.
 6. The method of claim 1,further comprising: calling a scene object builder; identifying aplurality of elements from the design model with the scene objectbuilder; and locating an object builder that corresponds to eachidentified element; wherein acts of creating a parametric representationof the feature and creating the non-parametric boundary representationof the feature are performed by the object builder.
 7. The method ofclaim 1, wherein the act of creating the non-parametric boundaryrepresentation includes executing a solid differences algorithm.
 8. Themethod of claim 1, wherein the act of creating the non-parametricboundary representation includes executing a facial differencesalgorithm.
 9. The method of claim 1, wherein the act of creating thenon-parametric boundary representation includes executing a boundarydifferences algorithm.
 10. A computer readable data structure forcreating non-parameterized boundary representations used for exchangingdata between a source computer aided design (“CAD”) system and a targetCAD system, comprising: a parametric representation of a plurality offeatures in a parametric design model, the features being extracted andinterpreted from the source CAD system in a format other than a nativeformat of the feature; and a plurality of non-parameterized boundaryrepresentation, for each of the plurality of features in the parametricdesign model, which supplements the parametric representation, at leastone of the plurality of non-parameterized boundary representationscreated with a facial differences algorithm.
 11. The computer readabledata structure of claim 10, wherein at least one of the plurality ofnon-parametric boundary representations is created using techniquesincluding a solid differences algorithm.
 12. The computer readable datastructure of claim 10, wherein at least one of the plurality ofnon-parametric boundary representations is created using techniquesincluding a boundary differences algorithm.
 13. A computer implementedmethod for importing a parametric CAD model of a solid having aplurality of features from a source CAD system into a target CAD system,comprising: exporting a representation of the source CAD model, theexported CAD model including a parametric representation and anindividual non-parametric boundary representation for each of theplurality of features; importing the parametric representation for eachof the plurality of features into the target CAD model in a format otherthan a native format of the source CAD design model; and using theindividual non-parametric boundary representation of any feature thatfails the step of importing the parametric representation of the samefeature; and storing the imported representations of the plurality offeatures in the target CAD system.
 14. The computer implemented methodof claim 13, wherein said act of importing includes: attempting animport action for each parametric representation, and attempting arewrite action for each feature where the import action fails.
 15. Thecomputer implemented method of claim 13, further comprising importingthe non-parametric boundary representation for each of the plurality offeatures into the target CAD data model, regardless of whether theimport action fails.
 16. An apparatus for use with a source computeraided design model and a target computer aided design model, theapparatus comprising: a processor; and a memory coupled to saidprocessor; wherein said memory is configured to contain computer programcode adapted to cause the processor to: (a) load a parametric designmodel from a source CAD system, the design model including a pluralityof features; (b) classify a first feature from the plurality of featuresusing a knowledge base to determine a type of operation that created thefirst feature; (c) create a non-parametric boundary representation fromthe first feature, based on the code for classify, until thenon-parametric boundary representation is inclusive of the firstfeature; (d) store the non-parametric boundary representation for accessby a target CAD system; and repeat (b), and (d) for each additionalfeature from the plurality of features.
 17. The apparatus of claim 16,wherein the memory is further adapted to cause the processor to: (e)create a parametric representation of the first feature (f) associatethe parametric representation of the first feature with thenon-parametric boundary representation of the first feature; and repeat(e) and (f) for additional features from the plurality of features. 18.The apparatus of claim 17, wherein (e) is further adapted to cause theprocessor to perform a pattern matching technique.
 19. The apparatus ofclaim 18, wherein (e) is further adapted to cause the processor toperform a user emulation technique.
 20. A computer readable datastructure for creating non-parameterized boundary representations usedfor importing and exporting data between a source computer aided design(“CAD”) system and a target CAD system, comprising: a parametricrepresentation of a plurality of features in a parametric design model,the features being extracted and interpreted from the source CAD systemin a format other than a native format of the feature; and a pluralityof non-parameterized boundary representation, for each of the pluralityof features in the parametric design model, which supplements theparametric representation, at least one of the plurality ofnon-parameterized boundary representations created with a boundarydifferences algorithm.
 21. The computer readable data structure of claim20, wherein at least one of the plurality of non-parametric boundaryrepresentations is created using techniques including a soliddifferences algorithm.
 22. The computer readable data structure of claim20, wherein at least one of the plurality of non-parametric boundaryrepresentations is created using techniques including a facialdifferences algorithm.